System and method utilizing test notifications

ABSTRACT

A system and method utilizing test notifications. An application is able to construct a test notification that is sent to a user context system and which receives back an indication whether the notification would draw or not draw on the screen at the present time, in accordance with the user&#39;s current context. In another embodiment, the calling application receives back richer indications, such as details as to whether the notification would have been deferred or routed, the sound level at which it would have played, etc. In a polling implementation, an application may periodically re-send test notifications to re-poll the system to determine if changes have occurred. In a subscription implementation, an application may subscribe to the system to receive updates that are provided when there are changes.

CROSS-REFERENCE(S) TO RELATED APPLICATION(S)

[0001] This application is related to U.S. application attorney docketnumber MSFT-1-20461, titled “Extensible User Context System for Deliveryof Notifications,” filed concurrently with the present application,which is hereby incorporated by reference in its entirety.

FIELD OF THE INVENTION

[0002] The present invention relates to notifications in computingsystems, and more particularly, a system and method utilizing testnotifications.

BACKGROUND OF THE INVENTION

[0003] In computer systems, a notification may be in the form of asignal from a program that indicates to a user that a specified eventhas occurred. Such a notification may contain various elements of text,sound, and graphics. Other properties may also be included with thenotification, such as priority, the person who sent the notification(for channels such as e-mail or instant messaging), and when thenotification expires. Notifications may also include some elements ofcode such that the user can interact with the notification and launcharbitrary code (e.g., clicking on buttons or text within thenotification that can cause new programs to launch or actions to betaken on programs that are currently running).

[0004] An operating system may create notifications to let a user knowabout network connectivity and updates. A instant messaging program thatuses “contact lists” may draw notifications on the screen to let theuser know what is happening with the contact list or when a contactinitiates an instant message conversation. Other programs may providesimilar notifications that draw in similar areas of the display. Oneissue with these types of notifications is that they aren't generallyaware of the other notifications, thus sometimes leading tonotifications being drawn on top of other notifications.

[0005] Another issue with existing notification systems is that they maycause notifications to be delivered inappropriately, or at inappropriatetimes. For example, for a user providing a full screen presentation, itmay be inappropriate to have other programs draw notifications on thescreen during the presentation. An example of a program that might drawsuch inappropriate notifications is a instant messaging program thatruns in the background of the operating system and draws suchnotifications when contacts in the contact list sign on or initiate aninstant message. This type of “interruption” during a presentation maybe undesirable to a user.

[0006] The present invention is directed to providing a system andmethod that overcome the foregoing and other disadvantages. Morespecifically, the present invention is directed to a system and methodutilizing test notifications.

SUMMARY OF THE INVENTION

[0007] A system and method utilizing test notifications is provided. Inaccordance with one aspect of the invention, a calling programconstructs a test notification that is similar to an actualnotification. A key difference from an actual notification is that thetest notification will not actually be delivered to the user.

[0008] In accordance with another aspect of the invention, in oneembodiment the test notification returns an indication of true or false.An indication of true means that an actual notification would have drawnat the present time, while an indication of false means that an actualnotification would not have been able to draw at the present time. Inanother embodiment, richer return values may also be returned by thetest notification. Examples of richer return values include whether thenotification would have been deferred or routed, the sound level atwhich the notification would have played, etc.

[0009] In accordance with another aspect of the present invention, inone embodiment a polling method is utilized. In this embodiment, thecalling program periodically re-polls (sends test notifications) todetermine the user's current context and how any broadcast data shouldbe changed that are sent by the calling program. An example of broadcastdata could be a instant messaging program broadcasting a busy or freestate to a contact. In another embodiment, a subscription callbackmethod is utilized. In this embodiment, the calling program subscribesto receive context changes. In other words, rather than re-pollingperiodically, as the user's context changes as relevant to the type ofinformation that is broadcast, the context engine calls back to theprogram with these updates. This latter embodiment has an advantage inthat there is no lag between the context changes and what is broadcast.In other cases, the polling method may be more appropriate, such as forone-time events.

[0010] It will be appreciated that the testing system and method of thepresent invention allows the operating system and arbitrary programs todetermine when it is appropriate to send notifications to the user. Oneadvantage of utilizing test notifications is that by enabling a programto have a richer view of the user's context, unwanted actualnotifications can be prevented from being generated until a user is in areceptive state. In addition, greater flexibility is provided forprograms that do not utilize the same user interface for the delivery ofnotifications, in that by utilizing the test notifications they arestill able to obtain information as to the user's context. As anexample, a future program may develop a notification with specializedgraphics that might not be supported by a present user context system,however the future program would still be able to utilize informationobtained from a test notification to determine whether it is appropriateto send or modify its present notification.

[0011] In accordance with another aspect of the invention, the testnotifications are utilized in a user context system. The user contextsystem brokers and serializes the delivery of notifications frommultiple sources. In addition, a shared notion of user context isprovided, for determining the appropriate handling for each of thenotifications. In accordance with these aspects, the notifications thatare delivered by the user context system may be considered to be morevaluable in that they are delivered when the user is more receptive tothem. These aspects also provide for common rules which help the user toeliminate undesirable notifications. In one embodiment, the use of testnotifications in the user context system essentially provides for asystem tool or a system provided mechanism that is able to encapsulate auser's aggregated context and expose it to arbitrary processes.

[0012] In accordance with another aspect of the invention, in the usercontext system the contexts are declared by the operating system andarbitrary programs. In one embodiment, a user context comprises acondition that may be true or false, and an instruction that is to befollowed if the condition is true. For example, a condition might be“when a user is listening to music,” for which the instruction might be“deliver notifications on the screen but with no sound.” In general, thecondition for the user context can be thought of as a state that thesystem assumes makes the user in some way unavailable for notificationdelivery or that causes the way that the notification should bedelivered to be different from how it was sent by the program thatinitiated it. The user may be in a state deemed “unavailable” in whichcase the notification is either not delivered or held until the userbecomes “available.” For instance, if the user is running a full screenapplication, where the application is using or being displayed on thefull area of a display screen, that user may be deemed unavailable. Or,the user may be “available” but in such a state that the notificationneeds to be modified to be appropriate for the user.

[0013] In accordance with another aspect of the invention, in the usercontext system, in addition to the operating system declaring contexts,programs register with the system and declare the context they provideand the impact it has on notifications (as per if drawing on the screenis appropriate and the level of invasiveness that is appropriate fordrawing on the screen and whether or not sound is appropriate or at whatrelative volume sound should be played at) and then tells the systemwhether the context is true or false. In one embodiment, the context mayalso be evaluated as true or false at the time that a notification is tobe delivered. In one embodiment, the system may also track the processof the calling program, and if the process is no longer present, thecontext may be reset to false. By tracking the process, certainundesirable situations can be avoided, such as an application declaringa user as being busy, and then crashing, and then leaving the user stuckin a state in which they have been declared as not being available forreceiving notifications.

[0014] In accordance with another aspect of the invention, in the usercontext system, there may be different levels of invasiveness specifiedfor the drawing of notifications. In other words, based on the usercontext, there may be gradients for the drawing of notifications, suchthat there may be different levels of invasiveness in the form of thedrawn notification. For example, a normal notification may be free to bedrawn in the client area and briefly obscure a window. If the user is ina slightly restrictive context, the notification may be free to show,but only in a less invasive manner, such as it might not be allowed todraw on top of another window. As another example, if a user is runninga maximized application, the setting may be that the user context isslightly restricted, in that the user has clearly made a statement thatthey want their current application to get the entire client area. Inthis circumstance, notifications may still be allowed to draw, but theymay be made to only appear within the sidebar. This type of reducedinvasiveness in the notification drawing form lessens the impact of thenotifications, and lessens the cognitive load.

[0015] In accordance with another aspect of the invention, in the usercontext system the contexts that have been provided are exposed to theuser and can either be turned off (e.g., the user doesn't agree with theprogram's assessment of the context) or changed in terms of the impacton delivery.

[0016] In accordance with another aspect of the invention, in the usercontext system the user may define rules that dictate how notificationsthat contain specified elements should be delivered. For example, a userrule might dictate that any notifications received from “John Doe” andwith “urgent” in the subject line, should be delivered immediately. Inone embodiment, such user rules are given precedence over the usercontexts. The user rules are made available to the user for modificationin accordance with the user's preferences.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The foregoing aspects and many of the attendant advantages ofthis invention will become more readily appreciated as the same becomebetter understood by reference to the following detailed description,when taken in conjunction with the accompanying drawings, wherein:

[0018]FIG. 1 is a block diagram of a general purpose computer systemsuitable for implementing the present invention;

[0019]FIG. 2 is a flow diagram illustrative of a general routine forprocessing a notification in accordance with the present invention;

[0020]FIG. 3 is a flow diagram illustrative of a routine for anoperating system or arbitrary program declaring user contexts;

[0021]FIG. 4 is a flow diagram illustrative of a routine for evaluatinguser contexts as true or false at the time a notification API is called;

[0022]FIG. 5 is a flow diagram illustrative of a routine for adjustinguser contexts and creating new user rules;

[0023]FIG. 6 is a flow diagram illustrative of a routine for processinga notification in accordance with user contexts and user rules;

[0024]FIG. 7 is a flow diagram illustrative of a routine forimplementing user rules based on a notification's content and the usercontexts;

[0025]FIG. 8 is a flow diagram illustrative of a routine for deferringthe delivery of a notification;

[0026]FIG. 9 is a flow diagram illustrative of a routine for determininghow a notification will be drawn in accordance with various restrictivesettings;

[0027]FIG. 10 is a flow diagram illustrative of a routine fordetermining a volume level for a notification in accordance with variousrestrictive settings;

[0028]FIG. 11 is a flow diagram illustrative of a general routine forprocessing a test notification in accordance with the present invention;

[0029]FIG. 12 is a flow diagram illustrative of a routine for processinga test notification and returning indications of true or false;

[0030]FIG. 13 is a flow diagram illustrative of a routine for processinga test notification and returning indications with full details; and

[0031]FIG. 14 is a flow diagram illustrative of a routine for utilizinguser rules to process a test notification based on the testnotification's content and the current user contexts.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0032] The present invention is directed to a system and method thatutilizes test notifications. In one embodiment, the test notificationsmay be processed by a user context system. The user context systemcontrols the delivery of notifications.

[0033] In prior systems, there have typically been numerous competingelements which want to send notifications to a user, each of whichdesigns its own way to send such notifications. None of the competingelements have generally been aware of the other notifications and thushave tended to draw on top of each other and each other's applications,which can lead to conflicts when each chooses to render an indication oftheir respective notifications at the same time. Additionally, there hasbeen no shared notion of user context, leading to some notificationsbeing delivered inappropriately, or at inappropriate times. The usercontext system addresses these issues by building notifications as arich part of the operating system, such that the user interfaces fornotifications provided by the user context system become similar andthus stop conflicting with one another because the system appropriatelybrokers and serializes their on-screen rendering. In addition, thenotifications provided by the user context system can be considered tobe more valuable because they are delivered when the user is morereceptive to them, and in addition the use of common rules helps theuser to eliminate undesired notifications.

[0034] As noted above, the user context system may be utilized toprocess the test notifications of the present invention. The testnotifications of the present invention are used to determine if actualnotifications would be delivered under present conditions. In otherwords, the test notifications are intended to provide an indication ofwhether a user is currently available for receiving notifications. Thisindication, can be used, for example, to prevent a program fromattempting to send an actual notification at the present time, or tocause the program to modify the notification.

[0035]FIG. 1 and the following discussion are intended to provide abrief, general description of a suitable computing environment in whichthe present invention may be implemented. Although not required, theinvention will be described in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a personal computer. Generally, program modules includeroutines, programs, characters, components, data structures, etc., thatperform particular tasks or implement particular abstract data types. Asthose skilled in the art will appreciate, the invention may be practicedwith other computer system configurations, including hand-held devices,multiprocessor systems, microprocessor-based or programmable consumerelectronics, network PCs, minicomputers, mainframe computers, and thelike. The invention may also be practiced in distributed computingenvironments where tasks are performed by remote processing devices thatare linked through a communications network. In a distributed computingenvironment, program modules may be located in both local and remotememory storage devices.

[0036] With reference to FIG. 1, an exemplary system for implementingthe invention includes a general purpose computing device in the form ofa conventional personal computer 20, including a processing unit 21,system memory 22, and a system bus 23 that couples various systemcomponents including the system memory 22 to the processing unit 21. Thesystem bus 23 may be any of several types of bus structures including amemory bus or memory controller, a peripheral bus, and a local bus usingany of a variety of bus architectures. The system memory includesread-only memory (ROM) 24 and random access memory (RAM) 25. A basicinput/output system (BIOS) 26, containing the basic routines that helpsto transfer information between elements within the personal computer20, such as during start-up, is stored in ROM 24. The personal computer20 further includes a hard disk drive 27 for reading from or writing toa hard disk 39, a magnetic disk drive 28 for reading from or writing toa removable magnetic disk 29, and an optical disk drive 30 for readingfrom or writing to a removable optical disk 31, such as a CD-ROM orother optical media. The hard disk drive 27, magnetic disk drive 28, andoptical disk drive 30 are connected to the system bus 23 by a hard diskdrive interface 32, a magnetic disk drive interface 33, and an opticaldrive interface 34, respectively. The drives and their associatedcomputer-readable media provide non-volatile storage ofcomputer-readable instructions, data structures, program modules, andother data for the personal computer 20. Although the exemplaryenvironment described herein employs a hard disk 39, a removablemagnetic disk 29, and a removable optical disk 31, it should beappreciated by those skilled in the art that other types ofcomputer-readable media which can store data that is accessible by acomputer, such as magnetic cassettes, flash memory cards, digital videodisks, Bernoulli cartridges, random access memories (RAMs), read-onlymemories (ROMs), and the like, may also be used in the exemplaryoperating environment.

[0037] A number of program modules may be stored on the hard disk 39,magnetic disk 29, optical disk 31, ROM 24 or RAM 25, including anoperating system 35, one or more application programs 36, other programmodules 37 and program data 38. A user may enter commands andinformation into the personal computer 20 through input devices such asa keyboard 40 and pointing device 42. Other input devices (not shown)may include a microphone, joystick, game pad, satellite dish, scanner,or the like. These and other input devices are often connected to theprocessing unit 21 through a serial port interface 46 that is coupled tothe system bus 23, but may also be connected by other interfaces, suchas a parallel port, game port or a universal serial bus (USB). A displayin the form of a monitor 47 is also connected to the system bus 23 viaan interface, such as a video card or adapter 48. One or more speakers57 may also be connected to the system bus 23 via an interface, such asan audio adapter 56. In addition to the display and speakers, personalcomputers typically include other peripheral output devices (not shown),such as printers.

[0038] The personal computer 20 may operate in a networked environmentusing logical connections to one or more personal computers, such as aremote computer 49. The remote computer 49 may be another personalcomputer, a server, a router, a network PC, a peer device or othercommon network node, and typically includes many or all of the elementsdescribed above relative to the personal computer 20. The logicalconnections depicted in FIG. 1 include a local area network (LAN) 51 anda wide area network (WAN) 52. Such networking environments arecommonplace in offices, enterprise-wide computer networks, intranets,and the Internet.

[0039] When used in a LAN networking environment, the personal computer20 is connected to the local area network 51 through a network interfaceor adapter 53. When used in a WAN networking environment, the personalcomputer 20 typically includes a modem 54 or other means forestablishing communications over the wide area network 52, such as theInternet. The modem 54, which may be internal or external, is connectedto the system bus 23 via the serial port interface 46. In a networkedenvironment, program modules depicted relative to the personal computer20 or portions thereof may be stored in the remote memory storagedevice. It will be appreciated that the network connections shown areexemplary, and other means of establishing a communications link betweenthe computers may be used.

[0040] The present invention may be implemented on a system of the typeillustrated in FIG. 1. As noted above, the test notifications of thepresent invention may be evaluated by a user context system. A usercontext system for evaluating the test notifications will primarily bedescribed with respect to FIGS. 2-10 below. The evaluation of the testnotifications will be described in more detail in later sections withrespect to FIGS. 11-14.

[0041] In regard to FIGS. 2-10, a user context system is provided forcontrolling the delivery of notifications from multiple sources. In oneembodiment, the user context system may consist of three elements thatare compared for a decision as to how to process a notification. Thefirst element is the user's context (as may be provided by the operatingsystem and arbitrary programs that have extended it). The second elementis the user's rules and preferences. The third element is thenotification itself (which contains elements such as data and propertiesthat may match the user's rules).

[0042] As will be described in more detail below, the user contextsystem operates by the operating system and other programs declaring auser's contexts, after which the system brokers the user's context andrules. Notifications are raised by other programs calling into thesystem. The user's context, rules, and elements of the notification arecompared and then a determination is made as to what should be done withthe notification. Examples of various options for what may be done withthe notification include denying (if the notification is not allowed todraw or make noise, and the notification is to never be seen by theuser), deferring (the notification is held until the user's contextchanges or the user's rules dictate that it is subsequently appropriateto deliver), delivering (the notification is allowed to be delivered inaccordance with the user's context and rules), and routing (the user'srules indicate that the notification should be handed off to anothersystem, regardless of whether the notification is also allowed to bedelivered in the present system).

[0043] Various routines for delivering a notification are described inmore detail below. In general, the user may be in a state deemed“unavailable” in which case the notification is either not delivered orheld until the user becomes “available”. For instance, if the user isrunning a full screen application, that user may be deemed unavailable.Or, the user may be “available” but in such a state that thenotification needs to be modified to be appropriate for the user. Forinstance, if the user is listening to music or in a meeting, the usermay have indicated that the notifications should be delivered to theuser's screen but that the sound they make should be either quieter ornot made at all.

[0044] As noted above, the user context determines in part whethernotifications are shown on the user's screen. When a notification isshown, it may be shown based on certain gradients within the usercontext. In other words, there are different levels of invasiveness ofthe form of the drawn notification that may be specified. For example, anormal notification is free to pop out into the client area and brieflyobscure a window. If the user is in a slightly restrictive context, thenotification may be free to show, but only in a less invasive manner,such as it might not be allowed to draw on top of another window. Asanother example, in one embodiment where the user is running a maximizedapplication, the default setting may be that this means that context isslightly restricted, and that the user has clearly made a statement thatthey want this application to get the entire client area. In thissetting, a notification may still be allowed to draw, but may be made toonly appear within the sidebar. In other words, this type of reducedinvasiveness in the notification drawing form lessens the impact of thenotification, and overall lessens the cognitive load.

[0045]FIG. 2 is a flow diagram illustrative of a routine 200 forprocessing a notification. At a block 202, the operating system or anarbitrary program calls a notification application programming interface(API). At a block 204, the elements of the notification are evaluatedwith respect to user contexts as set by the operating system andarbitrary programs, and as further approved or modified by the user, andwith respect to user rules as set by the user. At a block 206, anotification is delivered, deferred, denied, routed, or otherwisehandled in accordance with the user contexts and user rules.

[0046] The user contexts and user rules will be described in more detailbelow. In one embodiment, a user context consists of a condition thatmay be either true or false, and an instruction for determining how anotification should be handled when the condition is true. In general,the condition of a user context can be thought of as a state that thesystem assumes makes the user in some way unavailable for notificationdelivery or that causes the way that the notification is delivered to bedifferent from how it was sent by the program that initiated it. Inother words, in one embodiment a user context can be thought of as astatement that “while condition X is true, then this is what should bedone with incoming notifications.” An example would be “when my musicplayer is playing music for me, incoming notifications should show onthe screen but not play sound.” Another example would be “while anyapplication is running in full screen mode, incoming notificationsshould be deferred until later.”

[0047] With respect to such user contexts, in one embodiment a user mayalso define special rules for handling incoming notifications, and thusmay provide for special exceptions to the instructions of the usercontexts. As an example, a user rule might state “when I receive a newe-mail from ‘John Doe,’ and with ‘urgent’ in the text, and marked ‘highpriority,’ deliver the e-mail regardless of other user contexts.” Inother words, in this example this user rule provides an exception to auser context which would otherwise indicate that it is inappropriate todeliver a notification for an incoming e-mail at this time. With regardto the elements of the notification that the user rules are evaluatedwith respect to, these may include things like text, sound, graphics,and other properties such as priority, the person who sent thenotification (for channels such as email or instant messaging), when thenotification expires, and some elements of code such that the user caninteract with the notification and launch arbitrary code (e.g., clickingon buttons or text within the notification can cause new programs tolaunch or actions to be taken [such as deleting email] on programs thatare currently running).

[0048]FIG. 3 is a flow diagram illustrative of a routine 220 for anoperating system or arbitrary program declaring user contexts. At ablock 222, the operating system or program declares the default contextsand their impact on the user's busy state. In other words, programsregister with the system and provide user contexts including the impactthey have on the notifications (e.g., if drawing on the screen isappropriate and whether or not sound is appropriate or at what relativevolume sound should be played). As an example, a music player programmay declare a default context that states “when the music player isplaying music for the user, incoming notifications should show on thescreen but not play sound.” As another example, the operating systemmight declare a context which states “while any application is runningin full screen mode, incoming notifications should be deferred until alater time.”

[0049] Returning to FIG. 3, at a block 224, the operating system orprogram sets the declared context as true or false. For example, withregard to the music player declaring the context of “when the musicplayer is playing music, incoming notifications should show on thescreen but not play sound,” the music player program also sets thisdeclared context as currently being true or false. In other words, themusic player program indicates whether it is true or false that themusic player is currently playing music. As will be described in moredetail below, in one embodiment, the determination of whether a contextis true or false may also be evaluated at the time the notification APIis called, or at the time the user rules and exceptions arere-evaluated. As an additional feature, the system may also track theprocess handle of the calling program, such that if the processterminates without first resetting the context value to its default‘false’ value, the system will reset the context value as soon as itdetects that the initial process does not exist any more (in oneembodiment, the process handle state is set to signal when the processterminates, and that state change is picked up by the system whichwatches the process handle). This ensures that if processes terminateunexpectedly or forget to reset the context, then the delivery offurther notifications will not be unduly affected. For example, if inthe above example the music player program has been closed and theprocess is no longer present, then the context may automatically bereset to false. As another example, if a program originally declares auser as being busy, but then the program crashes, such that the processis no longer present, the context may automatically be set to falserather than leaving the user stuck in a state where notifications wouldnot be received. In any event, whether or not a context is actively setor is evaluated as a function, in one embodiment the contexts cangenerally be resolved to be either true or false.

[0050] Returning to FIG. 3, at a block 226, the context information isadded to the user contexts that are stored in the system. This processis repeated by additional programs declaring contexts. In addition, asnoted above, the state of whether already declared contexts are true orfalse will change over time as the user opens and closes differentprograms and undertakes different tasks.

[0051] As noted above, in one embodiment registering a context is adeclarative process. As will be described in more detail below, in theuser context system, by registering the user contexts, the user can bepresented with a list of the contexts so that the user can choose to notaccept certain contexts or to change what they mean if the userdisagrees with the context parameters. As noted above, in oneembodiment, a context may consist of a condition that may be true orfalse, and an instruction for what to do with notifications when thecondition is true. In this regard, a user context may comprise specificprogramming elements, such as: a human readable string (for the end userto know what is meant); a unique identifier (such as a globally uniqueidentifier, aka GUID) so that the program can tell the operating systemwhen this context is true or not; and the instruction which may comprisea statement of what this context means in terms of notifications drawingon screen (as may include invasiveness level, sound, and volume). Acontext may also be dynamic, as will be described in more detail below.

[0052]FIG. 4 is a flow diagram illustrative of a routine 230 for acontext to be evaluated as true or false at the time the notificationAPI is called. At a decision block 232, a determination is made whetherthe user contexts are to be evaluated at the time when the notificationAPI is called. If the user contexts are to be evaluated, then theroutine proceeds to block 234. If the user contexts are not to beevaluated at the time when the notification API is called, then theroutine ends. At block 234, the user contexts are evaluated as true orfalse.

[0053] As illustrated by FIGS. 3 and 4 and as noted above, a context maybe proactively set or it may be a function that is evaluated at arelevant time. As an example, a program may actively note that a user islistening to music. As another example, when a notification isevaluated, the program may have registered its callback such that theprogram is queried by the system at the time the notification isevaluated whether the context is true. One example of a case where thissecond process can be particularly important is when a user context iscombined with a user rule to form a dynamic context. (User rules will bedescribed in more detail below.) A specific example of a user contextcombined with a user rule would be when a user has set a rule thatstates “people who I'm meeting with right now can always send menotifications irrespective of my busy state.” In this case, the usercontext of “when the user is in a meeting,” must further be evaluated interms of who the user is in the meeting with. In this example, theprogram that handles the meetings may register this as a dynamiccontext, and when a notification is evaluated, the person who sent thenotification is evaluated against this context (which otherwise couldnot be declared as true or false proactively, since the people attendingthe meeting may change over time). In other words, this particularexample requires evaluation of a user's context in light of a user rulethat depends on other people's contexts.

[0054]FIG. 5 is a flow diagram illustrative of a routine 240 by which auser may adjust contexts and create new rules. At a block 242, adetermination is made whether the user wishes to adjust the contexts. Ifthe user does not wish to adjust the contexts, then the routine proceedsto a decision block 246, as will be described in more detail below. Ifthe user does wish to adjust the context, then the routine proceeds to ablock 244, where the user makes modifications to the contexts.

[0055] In one embodiment, the contexts that have been provided may beexposed to a user in a manner which allows the user to either turn thecontexts off (e.g., the user doesn't agree with the program's assessmentof the context), or to change the context in terms of the impact ondelivery of a notification. As more specific examples, user contexts caninclude things like “while any application is running in full screenmode”; “when I'm playing music or video”; “when my meeting manager showsme in a meeting”; or “when my out of office assistant is turned on.” Foreach of these, the user could be allowed to make selections that specifyan instruction that when the given condition is true, the incomingnotifications should follow selected procedures. The instructions canspecify things like whether or how the notification will draw on thescreen, and the sound or volume that the notification will make. For thevolume, the user can specify a percentage of desired volume under thegiven condition. For the options for drawing the notification on thescreen, the user can be provided with options such as not drawing thenotification at all, or drawing the notification only on a specifiedexternal display, or drawing the notification on the present screen. Forthe drawing of a notification, different levels of invasiveness can bespecified. For example, if a user is running a maximized application,such that the context is slightly restricted, the invasiveness settingmight be such that notifications can still draw, but might appear onlywithin a sidebar.

[0056] Returning to FIG. 5, at decision block 246, a determination ismade whether the user wishes to create new user rules. If the user doesnot wish to create new user rules, then the routine proceeds to adecision block 250, as will be described in more detail below. If theuser does wish to create new user rules, then the routine proceeds to ablock 248, where new rules are created. In general, user rules dictatehow notifications that contain specified elements should be handled. Forexample, a rule may dictate that notifications from a specified personshould always be delivered immediately, and this rule can be applied toall notifications, irrespective of which program initiated thenotification as long as it is from the specified person. As morespecific examples, other user rules may be directed to things like “MSNauto's traffic alerts for Bremerton, Washington” and “important e-mailsfrom John Doe.” As an example of a user rule for an important e-mailfrom John Doe, the rule could dictate that any e-mails that arrive fromJohn Doe, and with “urgent” in the text, and marked “high priority,”should follow specified handling conditions. The handling conditionscould specify that the notification should be delivered immediately andthat the user should be required to acknowledge it. In general,requiring a user to acknowledge a notification means that there is aslightly raised elevation in the form of the notification'sinvasiveness, in that the notification will stay on-screen until theuser specifically dismisses it. In one embodiment, the requiring of auser's acknowledgement is only settable via a user rule. As anotherexample, the rules could also specify a custom sound to be played forthe notification, at a specified volume, so as to provide an alert tothe user that a special notification has arrived. Different settings mayalso be selected for how the notification should be handled during“normal” and “busy” conditions for the user, as may be determined by theuser's context. The handling instructions may also include things likerouting options for the notification, such as “deliver notificationsfrom John Doe to my pager.” In one embodiment, when the context isevaluated, the most restrictive currently true context is the one thatis applied. When user rules are evaluated, it means that a particularnotification has matched the rule that the user has created, in whichcase the most invasive setting is applied from the user rules which havematched the notification. In other words, in the user rules, a user hasspecified something to be of importance, and this procedure is intendedto follow the user's preferences. If there is a conflict between tworules, the most invasive is applied.

[0057] In one embodiment, the user rules may also be directed tocontrolling the delivery of notifications from specific notificationservices. For example, an operating system that provides notificationsin accordance with a notification service may provide the user with away to modify how the notifications are delivered. For example, thespecified notification service may provide “traffic alerts for Seattle”,and the user may edit the delivery to be such that when suchnotifications are received the system should “show the notification andplay sound.”

[0058] Returning to FIG. 5, at decision block 250, a determination ismade whether the user wishes to adjust any of the already existing userrules. If the user does not wish to adjust any of the rules, then theroutine ends. If the user does wish to adjust the user rules, then theroutine proceeds to a block 252, where the user makes modifications tothe rules.

[0059] As described above with respect to FIGS. 3-5, the user contextsand user rules are set by the operating system, programs, and the user.The system appropriately brokers and serializes the delivery of thenotifications in accordance with the user's preferences. The usercontexts and user rules may be exposed to the user such that the usercan modify or adjust the various contexts and rules, or create newrules. This provides the user with a centralized way to managepreferences for how notifications are handled. It will be appreciatedthat this allows a user to effectively manage the many competingelements in a computing system that may want to send notifications tothe user.

[0060]FIG. 6 is a flow diagram illustrative of a routine 300 forprocessing a notification in accordance with user contexts and userrules. At a block 302, the operating system or an arbitrary programcalls the notifications API. At a decision block 304, a determination ismade whether the notification should be logged to the notificationhistory. If the notification is to be logged, then the routine proceedsto a block 306, where the notification is logged to the history. If thenotification is not to be logged, then the routine proceeds to adecision block 310.

[0061] At decision block 310, a determination is made whether thenotification matches any user rules. If the notification matches anyuser rules, then the routine proceeds to a block 312, where the userrules are followed (based on the notification content plus the usercontexts), and the routine continues to a point A that is continued inFIG. 7. If at decision block 310 the notification does not match anyuser rules, then the routine continues to a decision block 320.

[0062] In one embodiment, user rules always outweigh the current usercontexts. As noted above, user rules can be based on any element of thenotification. For example, a rule that is based on an evaluation of theperson who initiated the notification, can be applied to allnotifications, irrespective of which program initiated the notificationas long as it is from the person on which the rule is based (e.g., “JohnDoe” can always reach me). In addition, notifications may draw on thescreen even during contexts that would otherwise cause it not to draw(e.g., “people who are in a meeting with me can always send menotifications”, even though the user context generally states that theuser is not to receive notifications during a meeting).

[0063] Returning to FIG. 6, at decision block 320, a determination ismade whether the notification can draw at the present time (based on theuser context only). If the notification can draw at the present time,then the routine continues to a block 322, where the notification isdrawn, and appropriate sound and volume are provided. If it is notappropriate to draw the notification at the present time, then theroutine proceeds to a decision block 330.

[0064] At the decision block 330, a determination is made whether thenotification has expired. If the notification has expired, then theroutine proceeds to a block 332, where the notification is destroyed. Ifthe notification has not expired, then the routine proceeds to a block334, where the notification is deferred, and the routine continues to apoint B that is continued in FIG. 7.

[0065]FIG. 7 is a flow diagram illustrative of a routine 350 forprocessing a notification in accordance with specified user rules. Theroutine is continued from a point A from FIG. 6, as described above. Asillustrated in FIG. 7, at a decision block 352, a determination is madewhether the notification should be routed. If the notification is not tobe routed, then the routine continues to a decision block 362, as willbe described in more detail below. If the notification is to be routed,then the routine proceeds to a block 354, where the notification isrouted as specified. When a notification is routed, it indicates thatthe notification contains elements that match the user's rules thatrequire the notification to be handed off to another system. This mayhappen if the user is busy, or it may happen on every notification thatmatches the criteria specified in the user's rules, whether or not theuser is unavailable. As an example, a notification with the word“urgent” in it might always be forwarded to the user's pager, whereasother notifications might only be routed based on a combination of theuser's rules and context.

[0066] Some examples of routing instructions include: “Forward thisnotification to an e-mail address”; “forward this notification toanother PC”; “forward this notification to a pager”; “forward thisnotification to a cell phone”; or “forward this notification to ane-mail server.” As will be described in more detail below, if thenotification is routed, it may also be delivered and draw on the screen.In addition, the device to which the notification is forwarded may havethis same context system implemented, and on that device there may beadditional or different knowledge of the user's context, and the contextsystem on that device may choose to do different actions with thenotification.

[0067] Returning to FIG. 7, at decision block 362, a determination ismade whether to deny the notification. If the notification is not to bedenied, then the routine continues to a decision block 366, as will bedescribed in more detail below. If the notification is to be denied,then the routine proceeds to a block 364 where the notification isdestroyed and not seen by the user. In other words, a notification thatis denied is not allowed to draw or make noise. For example, this mayoccur based on a user rule that states that a certain notificationshould be denied, or as described above with reference to block 332 ofFIG. 6, when a notification has expired.

[0068] Returning to FIG. 7, at decision block 366, a determination ismade whether the notification should be deferred. If the notification isnot to be deferred, then the routine proceeds to a decision block 370,as will be described in more detail below. If the notification is to bedeferred, then the routine proceeds to a block 368, where thenotification is held until a user context changes, and the routinecontinues to a point B that is continued in FIG. 8. In general,deferring a notification indicates that the notification will be allowedto be delivered, but that the user's current context or rules are suchthat it is deemed inappropriate to deliver the notification at thistime. As will be described in more detail below with reference to FIG.8, once the user's context changes or alternatively when the user'srules indicate that it is subsequently appropriate, the notificationwill be delivered to the user's screen and allowed to draw and/or makeits sound, as dictated by the user rules and user context.

[0069] Returning to FIG. 7, at decision block 370, a determination ismade whether the notification should be delivered. If the notificationis not to be delivered, then the routine ends. If the notification is tobe delivered, then the routine proceeds to a block 372, where thenotification is drawn in accordance with the appropriate level ofinvasiveness, and the appropriate sound and volume are provided. Inother words, the notification is allowed to be delivered, though it isdelivered in accordance with the user's context and rules (e.g., anotification may be allowed to be drawn but required to be silent).

[0070]FIG. 8 is a flow diagram illustrative of a routine 380 fordeferring the delivery of a notification. The routine is continued froma point B from either FIGS. 6 or 7, as described above. As illustratedin FIG. 8, at a block 382, the notification is held. At a block 384, thesystem monitors for changes to the declared contexts as being true orfalse, or for a user rule dictating that it is now appropriate todeliver the notification. At a decision block 386, a determination ismade whether a user context has changed, or a user rule dictates that itis now appropriate to deliver the notification. If a user context hasnot changed and if no user rule otherwise dictates, then the routinereturns to block 382, where the notification continues to be held. Ifthe user context has changed or if a user rule dictates that it may nowbe appropriate to deliver the notification, then the routine proceeds toa point C which is continued in FIG. 6. Point C in FIG. 6 returns to thedecision block 304, where the process for evaluating the notificationstarts over.

[0071]FIG. 9 is a flow diagram illustrative of a routine 400 fordetermining the drawing of a notification in accordance with variousrestrictions. It will be appreciated that this routine may beimplemented as part of the processing of notifications, such as at block322 of FIG. 6 or block 372 of FIG. 7. In general, when a notificationenters the system, an evaluation is made of all of the contexts that arecurrently true, and the most restrictive settings for the notificationare applied in accordance with the user's current state. As illustratedin FIG. 9, at a decision block 402, a determination is made whether thenotification should not be drawn at all. If the notification is not tobe drawn at all, then the routine proceeds to a block 404, where thenotification is set to not be drawn on any display. If the notificationis to be drawn, then the routine proceeds to a decision block 406.

[0072] At decision block 406, a determination is made whether thenotification should be drawn but only externally. If the notification isonly to be drawn externally, then the routine proceeds to a block 408,where the notification is drawn but only on external hardware displays.If the notification is not to be drawn on external hardware displays,then the routine proceeds to a decision block 410.

[0073] At decision block 410, a determination is made whether thenotification should be drawn on the present display. If the notificationis to be drawn on the present display, then the routine proceeds to ablock 412, where the notification is drawn in accordance with theappropriate level of invasiveness on the present display. If thenotification is not to be drawn on the present display, then the routineends.

[0074]FIG. 10 is a flow diagram illustrative of a routine 420 fordetermining the volume that will be played for the sound of anotification, in accordance with various restrictions. As was describedabove with respect to FIG. 9, it will be appreciated that this routinemay be implemented as part of the processing of notifications, such asat block 322 of FIG. 6 or block 372 of FIG. 7. When the notificationenters the system, an evaluation is made of all the contexts that arecurrently true, and the most restrictive settings are applied to thenotification in accordance with the user's current state. As illustratedin FIG. 10, at decision block 422, a determination is made whether thenotification should be muted. If the notification is to be muted, thenthe routine proceeds to a block 424, where no volume is provided for thenotification. If the notification is not to be muted, then the routineproceeds to a decision block 426.

[0075] At decision block 426, a determination is made whether thenotification should be provided with some percentage but less than fullvolume. If some percentage volume is to be provided, then the routineproceeds to a block 428, where the notification is played at thespecified percentage volume. If a specified percentage volume is not tobe provided, then the routine proceeds to a decision block 430.

[0076] At decision block 430, a determination is made whether fullvolume should be provided for the notification. If full volume is to beprovided, then the routine proceeds to a block 432, where thenotification is played at the full volume level. If full volume is notto be provided, the routine ends. In one embodiment, in addition toproviding for different volume levels for the notification, differentsounds may also be selected for the notification in accordance with theuser context and rules.

[0077] It will be appreciated that the user context system as describedabove with respect to FIGS. 1-10, controls the delivery of notificationsfrom various sources such that the notifications stop conflicting withone another because the system appropriately brokers and serializestheir on-screen rendering. In addition, the notifications that areprocessed by the user context system can be considered to be morevaluable because they are delivered when the user is more receptive tothem, and in addition the use of common rules helps the user toeliminate undesired notifications.

[0078]FIGS. 11-14 are directed to the evaluation of test notifications.As will be described in more detail below, in accordance with one aspectof the present invention the test notifications can be utilized by anyprogram to obtain information about the current state of a user context.One advantage of this aspect is that the user context information can beobtained by any program, regardless of whether the program intends touse the service already built in the system, or whether the program isto extend it by rolling its own interpretation of what the notificationshould look like or the way it should be delivered. In other words,future programs with more advanced notifications that are not designedto be limited by the rendering provided to them by the system will stillbe able to utilize test notifications to obtain information about theuser's current context. Such more advanced notifications are likely tooccur as the richness of notifications continues to grow and change, andnew user interfaces for notifications continue to develop.

[0079] As an example, a future user interface may provide rich fullscreen animations that draw only when the user is not “busy.” Forinstance, placing a CD into the CD-ROM drive might present an animationof a CD on the screen, while the CD-ROM spins up (due to technicalconstraints, there is a period of time from when the CD is firstinserted until the CD may be read even though it is known to be in thedrive—and during this time period an animation could be used to show theuser that the system is aware of the CD, but just can't read from ityet). By using the test notifications of the present invention, theanimation program will be able to know about the user's current contextand can choose to not show on-screen if the user is not receptive tonotifications right now.

[0080] As another example, a future instant messaging program maydevelop a new user interface for notifications that could not be donewith the current notification engine. The development of such new userinterfaces is needed as part of the flexibility that is required in thecurrent competitive marketplace. In accordance with the presentinvention, test notifications could continue to be utilized by theinstant messaging program to determine whether it should show/not showits more advanced notifications in accordance with user's currentcontext.

[0081] In accordance with another aspect of the present invention, thetest notifications can be utilized to prevent unwanted notificationsfrom being generated. This aspect can be applied to any programs thatattempt to send notifications to the system. In other words, by enablinga program to have a richer view of the user's context, unwantednotifications can be prevented from being generated by the programs,thus proactively ending the generation of these types of notificationsuntil the user is in a receptive state. The following examples helpillustrate this aspect of the invention.

[0082] As one example, a instant messaging program may provide a list ofcontacts. The test notifications are able to tap into the context systemon a per-contact basis (e.g., “if Tom were to send you an instantmessage right now, would it show ?” and “if Chris were to send you aninstant message right now, would that show ?”). On the basis of thisinformation, the instant messaging program can begin broadcastingdefinite busy or free states to individual contacts. This techniquecould be used to preemptively stop unwanted notifications from beinggenerated, rather than simply suppressing them once they are received.

[0083] As another example, if a user is busy, a mail program could makeuse of this to provide an automated reply to the sender (either to allsenders based on rules that the user has provided, such as “my directreports” or “my manager”). The automated reply could indicate “I am busyright now, but will respond when I have a chance.” In general, thecommunications of the system as a whole can be improved by exposing theuser's context to arbitrary programs.

[0084] As described above, in accordance with the present invention, anapplication is able to construct a test notification and receive backspecifically whether or not an actual notification would draw on thescreen at the present time. As noted above, this allows programs tocontinue to use the user context system even after new user interfacesfor notifications are developed. In addition, by enabling these newricher scenarios for other programs, all programs that utilize thesystem can be considered to be richer and more intelligent based onhaving increased access to information about the user's behavior andpreferences.

[0085]FIG. 11 is a flow diagram illustrative of a general routine 500for processing a test notification in accordance with the presentinvention. The routine is similar to the routine of FIG. 2 forprocessing an actual notification. As illustrated in FIG. 11, at a block502, the notification test API is called. At a block 504, the elementsof the test notification are evaluated with respect to the user contextsas set by the operating system and arbitrary programs and as furtherapproved or modified by the user, and with respect to any user rules asset by the user. At a block 506, in accordance with the evaluation ofthe test notification, an indication is provided regarding how the testnotification would be handled. The indication is then returned to thecalling application.

[0086] In one embodiment, the notification test API is called when theoperating system or an arbitrary program decides that it needs tounderstand how busy the user currently is. One example of when thismight occur would be when there is a decision point for whether or notto draw a notification on the screen. Another example would be to usethis data to inform an action that the program wants to take on theuser's behalf.

[0087] When the notification test API is called, the calling programconstructs a notification that is as close to what it would send if itwere using the notification methods of the user context system forsending an actual notification, and then uses an optional method to test(which returns the result and also guarantees that this particularnotification will not be shown on-screen). One example of this processwould be a instant messaging program wanting to broadcast an appropriatefree or busy state to each contact based on the current user's context.The instant messaging program would create a test notification for eachcontact, and based on the return value broadcast a different free orbusy state on a per-contact basis. Another example would be a programwanting to show an animation based on a user context (e.g., the CD-ROManimation example described above). The code that wants to show theanimation would construct a notification (in this case, the contentssimply being a simple notification with an image or animation sequenceas this is just a test as to whether or not the given notification woulddraw), and then uses the test method, and then the return results couldbe used as a guide for whether or not the animation should currently beplayed. In one embodiment, the calling code will generally at leastraise the most-generic notification possible as a test notification. Ifthere is richer data available (such as the contact from the contactlist), then including this information makes the test notification moreaccurate as the user may have custom user rules on a per person basisthat may affect the returned results.

[0088] One implementation that may be utilized for the notification testAPI is a polling implementation. In the instant messaging programexample described above, for the polling implementation the instantmessaging program would periodically re-poll the notification test APIto determine how to change the broadcast data. Another implementationthat can be utilized for the notification test API is a subscriptioncallback implementation. In this implementation, the instant messagingprogram would “subscribe” to context changes. Then, rather thanperiodically re-polling, as the user context changes in ways that changewhat the instant messaging program would be able to broadcast, thecontext engine can call back to the instant messaging program withappropriate updates. In some scenarios, this is advantageous, in thatthere is no lag between the context changes and what is broadcast(whereas with the polling implementation, there will tend to be momentswhen the broadcast state does not match the current user context). Forother scenarios, the polling implementation may be more appropriate (asthese are responses to one-time events, e.g., a CD being inserted into aCD-ROM).

[0089]FIG. 12 is a flow diagram illustrative of a routine 520 forprocessing a test notification and returning an indication of true orfalse for whether or not the test notification would draw at the presenttime. At a block 522, the notification test API is called. At a decisionblock 530, a determination is made whether the test notification matchesany user rules. If the test notification does not match any user rules,then the routine proceeds to a decision block 550, as will be describedin more detail below. If the test notification does match any userrules, then the routine proceeds to a decision block 540.

[0090] At decision block 540, a determination is made whether the userrules indicate that the test notification would draw at the presenttime. If the test notification would draw at the present time, then theroutine proceeds to a block 542, where an indication of true isprovided. If the test notification would not draw at the present time,then the routine proceeds to a block 544, where an indication of falseis provided.

[0091] At decision block 550, a determination is made whether the testnotification would be able to draw at the present time (in relation tothe user context only). If the test notification would be able to drawat the present time, then the routine proceeds to a block 552, where anindication of true is provided. If the notification would not be able todraw at the present time, then the routine proceeds to a block 554,where an indication of false is provided. From blocks 542, 544, 552 and554, the routine returns to the calling application with the designatedindication.

[0092]FIG. 13 is a flow diagram illustrative of a routine 600 forprocessing a notification and returning detailed indications. As notedabove, the routine 520 of FIG. 12 only provides a return value with anindication of true or false, with regard to whether or not thenotification would draw at the present time. As will be described inmore detail below, the routine 600 of FIG. 13 returns richer returnvalues (e.g., the notification would not draw right now, but it woulddraw as soon as the user's context changes, or it would route to anotherdevice, etc.). This provides for richer logic in the calling code. Thisallows for advanced functionality in programs that are able to utilizesuch richer return values.

[0093] It should also be noted while the return values are beingdescribed as part of a function call, in another embodiment this datamay be passed as part of a callback. In other words, the callingapplication can set up a “subscription” to a notification such that whena user's context subsequently changes (as would affect the delivery ofnotifications from the calling application) then the calling applicationis notified. This requires no polling, and in some cases is thus betterfor the robustness and performance of the system.

[0094] As illustrated in FIG. 13, at a block 602 the notification testAPI is called or a subscription is registered (as related to the pollingversus subscription embodiments described above). At a decision block610, a determination is made whether the test notification matches anyuser rules. If the test notification does not match any user rules, thenthe routine proceeds to a decision block 620, as will be described inmore detail below. If the test notification does match any user rules,then the routine proceeds to a block 612. At block 612, the testnotification is evaluated according to the user rules (based on the testnotification content plus the user contexts), and the routine continuesto a point D that is continued in FIG. 14, as will be described in moredetail below.

[0095] At decision block 620, a determination is made whether the testnotification would be able to draw at the present time (based on usercontext only). If the test notification would not be able to draw at thepresent time, then the routine proceeds to a decision block 630, as willbe described in more detail below. If the test notification would beable to draw at the present time, then the routine proceeds to a block622. At block 622, the routine determines what sound level would beappropriate according to the user context. At a block 624, an indicationis provided that the notification would draw, and also including thepercentage sound level that would be appropriate for the notification.

[0096] At decision block 630, the determination is made whether the testnotification would be held for later delivery (based on the testnotification content plus the user rules). If the test notificationwould be held for later, then the routine proceeds to a block 632 wherean indication is provided of defer. If the test notification would notbe held for later delivery, then the routine proceeds to a block 634,where an indication is provided of deny. From blocks 624, 632 and 634,the routine returns to the calling application with the specifiedindication(s).

[0097]FIG. 14 is a flow diagram illustrative of a routine 650 forevaluating a test notification in accordance with user rules. Theroutine continues from a point D from FIG. 13. As illustrated in FIG.14, at a decision block 652, a determination is made whether the testnotification should be routed. If the test notification is to be routed,then the routine proceeds to a block 654 where an indication of route isprovided, and the routine proceeds to a decision block 662. If the testnotification would not be routed, the routine also proceeds to decisionblock 662.

[0098] At decision block 662, a determination is made whether the testnotification would be denied. If the test notification would be denied,then the routine proceeds to a block 664, where an indication of deny isprovided. If the test notification would not be denied, then the routineproceeds to a decision block 666.

[0099] At decision block 666, a determination is made whether the testnotification would be deferred. If the test notification would bedeferred, then the routine proceeds to a block 668, where an indicationis provided of defer. If the test notification would not be deferred,then the routine proceeds to a decision block 670.

[0100] At decision block 670, a determination is made whether the testnotification would be delivered. If the test notification would bedelivered, then the routine proceeds to a block 672, where an indicationof deliver is provided. In one embodiment, the delivery indication mayalso include a specified invasiveness indication as well as a sound andvolume indication. If the test notification would not be delivered, thenthe routine returns to the calling application. From blocks 664, 668,and 672, the routine returns to the calling application with thespecified indications.

[0101] It will be appreciated that the present invention as describedabove with respect to FIGS. 1-14 provides a system and method utilizingtest notifications which enable programs to obtain indications as to theavailability of a user. By enabling a program to have a richer view of auser's context, the generation of unwanted notifications can beprevented at the source, thus allowing notifications to only begenerated when a user is in a receptive state. In addition, a program isable to utilize the test notifications to determine a user's context,even if the program generally utilizes a different user interface forits own notifications. These aspects allow for greater flexibility inthe potential uses of the user context system. These aspects also enablenew richer scenarios for other programs, such that the system as a wholecan become richer and more intelligent based on the user's behavior andpreferences.

[0102] While the preferred embodiment of the invention has beenillustrated and described, it will be appreciated that various changescan be made therein without departing from the spirit and scope of theinvention.

The embodiments of the invention in which an exclusive property orprivilege is claimed are defined as follows:
 1. In a computer systemthat delivers notifications to a user, a method utilizing testnotifications, comprising: receiving a test notification; evaluating thetest notification but not delivering the test notification to a user;and returning an indication as to the results of the evaluation of thetest notification.
 2. The method of claim 1, wherein the testnotification simulates an actual notification and the results of theevaluation indicate whether the actual notification would have beendelivered to the user.
 3. The method of claim 1, wherein the evaluationof the test notification is done according to a user context.
 4. Themethod of claim 3, wherein the user context comprises a condition thatmay be true or false and an instruction that is to be followed if thecondition is true.
 5. The method of claim 4, wherein the condition ofthe user context is intended to be related to the availability of theuser for receiving notifications, and the instruction relates to whetheror not a notification should be delivered to the user.
 6. The method ofclaim 1, wherein the evaluation of the test notification is doneaccording to a user rule that dictates how a notification that containscertain specified content is to be handled.
 7. The method of claim 1,wherein a polling method is implemented such that additional testnotifications are utilized to re-poll the system to determine whenspecified changes have occurred.
 8. The method of claim 1, wherein asubscription method is implemented such that the system automaticallyprovides indications when changes occur.
 9. The method of claim 1,wherein the indication as to the results of the evaluation of the testnotification comprises a delivery indication.
 10. The method of claim 9,wherein the delivery indication is either true or false.
 11. The methodof claim 9, wherein the indication further comprises one of a routing ordeferring indication.
 12. The method of claim 9, wherein the indicationfurther comprises an invasiveness indication.
 13. The method of claim 9,wherein the indication further comprises a volume indication.
 14. Acomputer-readable medium having computer-executable components forimplementing a method utilizing test notifications, comprising:receiving a test notification; evaluating the test notification but notdelivering the test notification to a user; and returning an indicationas to the results of the evaluation of the test notification.
 15. Themethod of claim 14, wherein the test notification simulates an actualnotification and the results of the evaluation indicate whether theactual notification would have been delivered to the user.
 16. Themethod of claim 14, wherein the evaluation of the test notification isdone according to a user context that comprises a condition and aninstruction that is to be followed depending on the state of thecondition.
 17. The method of claim 16, wherein the condition may be trueor false and the instruction is to be followed if the condition is true.18. The method of claim 17, wherein the condition of the user context isintended to be related to the availability of the user for receivingnotifications, and the instruction relates to whether or not anotification should be delivered to the user.
 19. The method of claim14, wherein the evaluation of the test notification is done according toa user rule that dictates how a notification that contains certainspecified content is to be handled.
 20. The method of claim 14, whereina polling method is implemented such that additional test notificationsare utilized to re-poll the system to determine when specified changeshave occurred.
 21. The method of claim 14, wherein a subscription methodis implemented such that the system automatically provides indicationswhen changes occur.
 22. The method of claim 14, wherein the indicationas to the results of the evaluation of the test notification comprisesat least one of a delivery indication, a routing indication, or adeferring indication.
 23. In a computer system that deliversnotifications to a user, a method utilizing test notifications,comprising: receiving a test notification that simulates an actualnotification; and evaluating the test notification and providing anindication as to whether the actual notification would have beendelivered.
 24. The method of claim 23, wherein the test notification wasreceived from a calling application, and the indication as to whetherthe actual notification would have been delivered is returned to thecalling application.
 25. The method of claim 23, wherein the evaluationof the test notification is done according to a user context.
 26. Themethod of claim 25, wherein the user context comprises a condition thatmay be true or false and an instruction that is to be followed if thecondition is true.
 27. The method of claim 26, wherein the condition ofthe user context is intended to be related to the availability of theuser for receiving notifications, and the instruction relates to whetheror not a notification should be delivered to the user.
 28. The method ofclaim 23, wherein the evaluation of the test notification is doneaccording to a user rule that dictates how a notification that containscertain specified content is to be handled.
 29. The method of claim 23,wherein a polling method is implemented such that additional testnotifications are utilized to re-poll the system to determine whenspecified changes have occurred.
 30. The method of claim 23, wherein asubscription method is implemented such that the system automaticallyprovides indications when changes occur.
 31. The method of claim 23,wherein the indication as to whether the actual notification would havebeen delivered further comprises additional indications as to how theactual notification would have been handled.
 32. A computer-readablemedium having computer-executable components for implementing a methodutilizing test notifications, comprising: receiving a test notificationthat simulates an actual notification; evaluating the test notificationand providing an indication as to whether the actual notification wouldhave been delivered.
 33. The method of claim 32, wherein the testnotification was received from a calling application, and the indicationas to whether the actual notification would have been delivered isreturned to the calling application.
 34. The method of claim 33, whereinthe evaluation of the test notification is done according to a usercontext.
 35. The method of claim 34, wherein the user context comprisesa condition that may be true or false and an instruction that is to befollowed if the condition is true.
 36. The method of claim 35, whereinthe condition of the user context is intended to be related to theavailability of the user for receiving notifications, and theinstruction relates to whether or not a notification should be deliveredto the user.
 37. The method of claim 33, wherein the evaluation of thetest notification is done according to a user rule that dictates how anotification that contains certain specified content is to be handled.38. The method of claim 33, wherein a polling method is implemented suchthat additional test notifications are utilized to re-poll the system todetermine when specified changes have occurred.
 39. The method of claim33, wherein a subscription method is implemented such that the systemautomatically provides indications when changes occur.
 40. The method ofclaim 33, wherein the indication as to whether the actual notificationwould have been delivered further comprises additional indications as tohow the actual notification would have been handled.
 41. A systemutilizing test notifications, comprising: means for receiving a testnotification; means for evaluating the test notification but notdelivering the test notification to a user; and means for returning anindication as to the results of the evaluation of the test notification.42. The system of claim 41, further comprising means for evaluating thetest notification according to a user context.
 43. The system of claim41, further comprising means for evaluating the test notificationaccording to a user rule.
 44. The system of claim 41, further comprisingmeans for implementing a polling method wherein additional testnotifications are utilized to re-poll the system to determine whenspecified changes have occurred.
 45. The system of claim 41, furthercomprising means for implementing a subscription method wherein thesystem automatically provides indications when changes occur.
 46. Asystem utilizing test notifications, comprising: means for receiving atest notification that simulates an actual notification; and means forevaluating the test notification and providing an indication as towhether the actual notification would have been delivered.
 47. Thesystem of claim 46, further comprising means for evaluating the testnotification according to a user context.
 48. The system of claim 46,further comprising means for evaluating the test notification accordingto a user rule.
 49. The system of claim 46, further comprising means forimplementing a polling method wherein additional test notifications areutilized to re-poll the system to determine when specified changes haveoccurred.
 50. The system of claim 46, further comprising means forimplementing a subscription method wherein the system automaticallyprovides indications when changes occur.